引子

担当就是为了把事情做成，担当力就是把事情做成的能力。然而人们对担当力却缺乏认识。展现了做事的激情就算有担当吗，事情做不成怎么办？做错后承担责任就叫有担当吗，事情没做成又有什么用？做到真正有担当，并不断提升担当力对于把事情做成非常重要。在本文中将提出担当力模型，将担当力分为 5 个级别，以帮助识别和提升担当力。

正文

担当力是把事情做成的能力，所以它既是能力的一部分，又与事情对应。

担当力模型中的事

担当力模型将事情分为 4 类，目标、责任、事情和任务。

首先是目标。这里的目标不是指做事的个人目标，例如我想加工资，而是这件事之所以存在的根本原因。因为目标才会有大家一起来做这件事的机会。例如：某公司希望开发一个移动应用为客户提供更好的服务，于是组建了一支开发团队。目标达成是做成事的唯一标准，即使移动应用开发出来了，但是并没有为客户提供更好的服务，这个开发团队不能叫成功。

其次是责任。责任首先是要达成目标，参与的人之间的分工，例如某人是这个移动应用的测试人员。责任其次是如果事情做的不好，参与者需要承担的那部分责任，例如软件出现故障，测试人员会承担没有提前找出该故障的责任。

再次是事情。为履行责任，可以清理出一些主要的事情。例如为提前找出重要的故障，测试人员有两件事情要做，一件是测试分析，另一件是测试验证。有人说责任和事情加在一起特别想岗位描述 JD，他们说的没错。

最后是任务。任务是责任、事情与具体的工作结合，有开始、完成的时间点，是计划的一部分。

担当力模型中的人

担当力模型将人的担当力分为 5 个级别。担当力的 5 个级别是包含关系，更高级别的担当力建立在较低级别担当力的基础上。

担当力的第一个级别是做任务，其特点是会去做，没有承诺，关键词：任务。处于这一级别的人主要关心任务的内容，他们会去做任务。他们不太关心整体计划和他们的任务与其他任务的关系。他们会：1）做任务。他们可能存在下列问题：1）被动等待准备工作完成；2）不会主动暴露自己做任务的信息。

担当力的第二个级别是承担任务，其特点是遵照计划，按时按质，关键词：计划，相关人员。处于这一级别的人开始关心整体计划，开始关心哪些人和他协作，自己的任务和其他人任务的关联关系。他们会：1）积极做好和推进自身任务的准备工作；2）自己的任务出现风险时通知相关人员或求助；3）关注自己任务的完成标准，力求按时按质完成。他们能帮助：1）参与到计划制定和变更中；2）任务推进，帮助相关人员做好任务准备工作。他们可能存在下列问题：1）对计划外事件缺乏准备；2）工作职责模糊，对侵犯职责范围的事不能很好处理。

担当力的第三个级别是承担事情，其特点是我的事情，绝不推脱，关键词：分工。处于这一级别的人开始关心自己的分工，能够区分工作计划与完成分工职责间的关系。他们会：1）知道如何将事情划分成任务，共同制定计划；2）强调分工职责，对计划外事件按照分工职责处理。他们能帮助：1）计划推进；2）处理意外。他们可能存在下列问题：1）工作职责过于清晰，对职责范围外的工作不能很好处理；2）过分对事，爱遵循流程，稍显僵化。

担当力的第四个级别是承担责任，其特点是责任之内，尽心尽力，关键词：履责。处于这一级别的人开始关心如何更好的履行自己的责任，开始意识到帮助其他人履行责任也是自己履行责任所需的工作。他们会：1）与团队一起梳理责任；2）处理意外。他们能帮助：1）观察履责情况，推动其他人员履责。

担当力的第五个级别是超越责任，其特点是为了目标，竭尽全力，关键词：目标。处于这一级别的人能够为了目标达成而奋斗，超越自己的责任范围。

担当力模型的由来

担当力的划分是被逼出来的。下面的案例你可能似曾相识，正是这众多案例带来的纠结，推动了担当力模型的出现。对下面的案例，你怎么看？

案例 1：该员工的表现到底是好还是不好？

主管对某员工的表现表示满意，因为从各方听到的反馈都是该员工能够完成自己的工作。近期，主管想推进一种新的工作方式，主要由该员工完成，这时，项目经理提出了反对意见。“我对他没信心。”“为什么，他一直能完成工作，你好像不能信任他？” 经过沟通发现，因为这位同学不能承担责任，项目经理试图让他承担事情的努力也失败了，在计划中安排了一些任务，他也只能完成部分任务。最后项目经理选择的方式是减少分配给他的任务，并且不断跟踪完成情况。对他来说，所有交给他的任务都完成了。他的表现是好还是不好呢？

案例 2：擅长沟通的人升职更快？

某技术男一直以来认为自己怀才不遇。他有一位朋友，以前不是 IT 专业毕业的，跨行过来从测试开始做。结果短短几年测试、SQA、测试经理，这位同学不断升职。反观自己，该技术男很不服气，一定是她和领导关系好。不久后，两位都离开了原来的公司，结果技术男一直发展不顺利，而另一位同学则一直顺风顺水，在多个公司深受领导重用。技术男服气了，原来能称作本事的不仅是专业能力啊。

案例 3：我们用了 Scrum，为什么人们不愿去认领任务？

某公司顺应潮流，上马了 Scrum，但是发现人们都不愿去认领任务。该公司管理层得出结论，我们的人素质还不够，还不能用敏捷，我们还是回到原来的模式吧。

案例 4：公司培训搞得热热闹闹，来的人却寥寥无几，人们为什么不愿意提升自己的能力？

每年的员工调查里面都有一个意见，公司没有提供足够的培训。而且公司每年的分析里面也指出人员缺乏足够的能力。于是不少公司都有了技术大学，有了 E-learning 平台，选拔了一堆讲师，周周都有培训。然而，来的人却寥寥无几，到底有多少人从这些培训中得到真正的收益？公司从其中得到了多少收益？

案例 5：“挑战者” 号航天飞机的故事——来自《程序员的职业素养》前言

Bob 大叔是软件研发界的大师，他是怎么看专业程序员的呢？1986 年 1 月 28 日，挑战者飞机失事，七名航天勇士魂断苍穹。Bob 大叔在书中这么谈职业素养：“而那些工程师呢？当然，工程师做了他们应该做的事情。他们通知了管理人员，并且极力捍卫自身立场。他们经由适当的渠道，调用了所有合适的沟通协议。他们做了在体系内力所能及的事情，只是最后不得不听从领导的决定。因此，看起来工程师可以毫无愧疚地置身事外了。但是，我不知道那些工程师之中，是否有人会躺在床上夜不能寐。”